1. Field of the Invention
The present invention relates generally to systems and methods used in Processing telephone calls, and more particularly to systems and methods for allowing telephone carriers to offer enhanced products and services to their subscribers.
2. Related Art
Deregulation of the long-distance telephone industry spawned the growth of numerous long-distance service providers, each vying for a share of the United States"" long-distance market. Thus far, the U.S. industry is dominated by three large companies: ATandT, MCI and Sprint. These large carriers have the resources and capital at their disposal to enable them to develop and provide a wide range of telephone-related services to their customers.
Perhaps less known, but still extremely important in the more than $50 billion interexchange U.S. long-distance market, are the smaller companies. In 1991, ATandT, MCI and Sprint controlled approximately 85 percent of the U.S. market. At this time, 12 medium-sized companies shared eight percent of the U.S. market. The remaining seven percent of the U.S. market was divided among nearly 320 small carriers.
The larger carriers are able to attract customers by offering a full range of services in addition to direct dial calling. These services include, but are not limited to: operator-assisted calling, full-feature calling cards, and specialized 800 number routing.
The strategy followed by the smaller carriers in attracting customers has been to offer excellent service and low-cost, direct-dial long-distance calling (e.g. 1+ calling). Many smaller carriers, for example, focus on a particular geographic market. By understanding the market""s calling patterns, the smaller carrier can maximize crucial economies and can attract subscribers by offering long-distance calling at rates lower than those offered by larger carriers.
Additionally, many smaller carriers use the fact that they are a small, local business in order to attract other local businesses as their clients. These carriers stress the ability to offer more personalized, responsive attention than some larger carriers may provide.
However, many of the smaller carriers are finding it increasingly difficult to compete with the larger carriers by offering direct-dial calling alone. For these carriers to attract and retain customers, they need the ability to offer the same range of features and services provided by some of the larger carriers. For example, a small carrier may have a small travel agency as a long-distance subscriber. As the travel agency grows, develops more business, and hires additional salespersons, the travel agency""s telephone services requirements also grow. The travel agency may want to offer calling cards to its salespersons who travel frequently. The travel agency may also want the ability to re-route an incoming call that was made to their 800 number. Such re-routing allows the travel agency to re-route incoming 800-number calls to any telephone number, a voice mailbox, or a pager. Additionally, the travel agency may want the ability for its office workers, clients and vendors to make operator-assisted calls.
Unfortunately, most smaller carriers can only provide direct-dial long distance service to its customers. If a smaller carrier wants to offer enhanced products to its customers, the smaller carrier has two choices. First, the smaller carrier may purchase its own telephone switching system and operator consoles. Second, the smaller carrier may purchase and resell the products of one of its larger competitors.
However, reliable, affordable, and scalable switching equipment is not commercially available. If a long-distance carrier wants to purchase its own equipment, the selection is limited to the large-scale complex switching systems that are currently available. Because these systems are costly, in most instances, the smaller carrier is forced to go through a larger carrier to obtain enhanced products.
Several problems arise out of the inability of smaller carriers to provide enhanced calling services. Four of these problems are now described.
First, the flexibility and customization options available to the smaller carriers in providing services are limited when they resell the products of their larger competitors. One reason for this is that those products were not designed with the smaller carriers"" needs in mind. For example, consider a smaller carrier that wants to offer a product like 800 number forwarding to its customers. The smaller carrier will want its customers to hear customized user prompts, including the identification of the carrier. The smaller carrier will also want to establish its own prices for the service. To further customize its systems, the carrier may want to change the way the call processes, or to add additional features such as the ability to route an 800 number to a voice mailbox.
In another example, the smaller carrier is unable to provide carrier-unique operator services. The cost of providing operator services prohibits most smaller carriers from hiring their own operators and purchasing the required equipment. Instead, smaller carriers typically purchase operator services from a competitor carrier or from operator service providers.
One drawback of having to use a competitor""s operators is the inability to custom brand the call. For example, when a customer of the smaller carrier places an operator-assisted call using a competitor carrier""s operators, she hears the operator of the competitor carrier thank her for using the competitor carrier""s services.
Another drawback of having to use another""s operators is the inability to custom-tailor call processing because the operator services provided and the operator responses cannot be customized. The smaller carrier has no control over the operators used by the competitor carrier or the operator service provider.
Relying on larger carriers for providing these enhanced products does not give smaller carriers the flexibility they desire. This is because smaller carriers cannot customize the products they obtain from the larger carriers to provide unique services to their subscribers.
A second problem is the range of services that can be provided by a smaller carrier is limited to the services that carrier can purchase from its competitors. As a result, the smaller carrier often cannot create innovative new products and services to offer its customers.
An additional problem is that the amount of fraudulent calling considered acceptable, and therefore not monitored or halted by a larger carrier, may be well above a level that is economically tolerable for the smaller carrier.
Another problem is the smaller carrier""s inability to get customized fulfillment material through a competitor carrier. For example, calling cards provided by a larger competitor carrier, in turn to be provided to the smaller carrier""s customers, often bear the name of the competitor carrier.
In summary, because the small carriers must rely on the larger competitor carriers for advanced products and services such as calling cards, operator assistance, 800 service, audiotext, voice mail, and the like, the smaller carriers cannot offer a full range of carrier-unique and customer-unique products. As a result, the smaller carriers lose part of their ability to compete in the U.S. long-distance market.
The problems of flexible control of a telephone network are not limited to the smaller carriers or the long-distance industry. All telephone carriers would benefit from the ability to offer popular, customized, value-added services. Commercially available hardware and conventional solutions to date, however, do not offer this ability.
The present invention is directed to a call processing system and method which provides a wide range of enhanced calling products and features to subscribers. The subscribers can include individual users as well as customers who, in turn, provide telephone service to their own clients (also called xe2x80x9cusersxe2x80x9d). These customers can include telephone carriers whose clients are subscribers of the carriers"" network and can also include other types of businesses.
The call processing system is implemented in such a way that customer-unique and user-unique customized products and features can be provided. The features, products and services provided can be extensively customized to provide system flexibility and to offer users the option of choosing the level and types of features, products and services they receive. Customization can also be provided at the business- or carrier-customer level so that these customers can choose the level and types of features, products and services they wish to make available to their clients.
The call processing system includes at least one network control processor (NCP) and at least one switch (for example, a matrix switch). The network control processor (NCP) is a unique combination of hardware and software configured to determine the type of call being placed, the type of handling to be provided to the call, and to control the routing of the call. Because the NCP makes call handling and routing determinations regarding each call received, the switch implemented can be a passive switch that simply responds to routing instructions received from the NCP. Thus, control of the call is maintained by the NCP.
One feature of the invention is that it provides call data associated with a call is provided to the NCP to enable the NCP to make call processing determinations. The call data can include information such as the originating (caller""s) phone number (the ANI), the called phone number, originating and terminating area codes, customer identification codes, and other like information. The NCP uses this call data to make determinations regarding the manner in which each individual call is to be handled and to instruct the switch on how to route the call.
According to this philosophy, only the audio portion of the call is routed to the switch. The call data is not routed to the switch. Therefore, all call processing and handling determinations are made by the NCP and the switch can be implemented as a passive device.
The call processing system can also include one or more operator consoles to provide operator assistance to callers. The operator consoles provided can be manual operator consoles (MOCs) staffed by human operators to provide a human operator interface to callers. Alternately the operator consoles can be automated voice response units (VRUs) that provide automated assistance to callers. Additionally, a customer service console (CSC) can be used to provide detailed customer assistance to subscribers.
When a call is received by the call processing system, the call data is routed to the NCP and the call audio to the switch. The NCP begins handling the call while the audio circuit is held at the switch. The NCP first assigns a callhandle to the call; this is a unique identifier that can be used to identify both the call and call handling operations performed in conjunction with the call.
Once a callhandle is assigned, the NCP determines the type of handling and/or processing the call requires. In one embodiment, this is accomplished by retrieving call parameters for the call. The call parameters indicate the type of call being placed, whether and what type of operator assistance is required, and other processing required for the call. The call parameters are contained in a data record that is retrieved based on the call data. The NCP uses the call data for each call to look up a data record that contains the call parameters for that call. Because different data records can be maintained for different combinations of call data, unique or custom call handling and/or processing can be defined down to the customer and/or user level.
The call parameters include information on how the call is to be processed in the call processing system. The call parameters include what are termed a xe2x80x9cDEF Record Numberxe2x80x9d and a xe2x80x9cBase Process Numberxe2x80x9d that point to a series of data records chained together to define the call processing required for the call. These records are termed xe2x80x9cDEF Records.xe2x80x9d DEF records are described in more detail below.
The call parameters also include information regarding whether operator assistance is required to handle the call. If operator assistance is required, call parameters include a device type list that indicates the type of operator assistance required. This list can specify whether a MOC, VRU, or CSC can be used to handle the call. Because call parameters can be uniquely defined for each customer and/or user, the operator services provided can be customized down to the same level, if desired. Thus, a particular caller can be defined as always receiving operator assistance from a human operator, or a particular call type (such as a calling card call) can always be designated to receive automated VRU handling initially. The device type list can also indicate that a less complex device, such as a recorded message playback device is required.
Call parameters can provide further specificity in the type of operator assistance required. For example, the call parameters can include a language type that indicates the particular call requires operator assistance in a specific language. When the NCP retrieves call parameters that indicate a specific language is required, the call is routed to an operator console that can provide assistance in that language. For example, when a call is received from a specific originating number, the call parameters retrieved for that number may indicate that Spanish-language operator assistance is desired. Again, as with the other call parameters, the determination is made based on call data associated with the call. Thus, the language provided to handle each call can be customized at the user and/or customer level.
If operator assistance is required, the NCP allocates an operator console to handle the call. The allocation is made based on the call parameters retrieved for the call. For example, if a device type list indicates that a MOC is desired, the call is routed to an available MOC. If no MOC is currently available, the call can be placed on a queue. Music and/or other messages can be provided to the caller while the call is queued. A status display provides a visual indication of the number of calls in the queue.
So that the correct device type can be allocated to handle a given call, the NCP maintains a list of consoles available to handle calls and those consoles currently handling calls. The list can include information about each console pertaining to the type of console, the languages that console can support, and other pertinent information. Thus, if a French-speaking human operator is required, the NCP checks the list to see if a MOC with a French-speaking operator is currently available. If available, that console is allocated to handle the call. If unavailable, the call is queued.
Once a console is allocated to handle a call, the NCP instructs the switch to route the call audio to the allocated console. Because the switch is routing only the call audio (and is not handling call data), the consoles can be treated as any other terminating point on the switch. Thus specific, or dedicated, operator console ports are not required on the switch.
The NCP also sends operator control data to the allocated operator console, informing the allocated console that a call is being routed to it. Included with the operator control data is the base process number, a DEF record number and other call information from the call data.
When the call audio is routed to the operator console, the operator requests information from the caller. A script is displayed on a screen on the operator console for the human operator to read. For an automated VRU, the script is a recorded or synthesized voice that prompts the caller for information. The particular script to be read or played is retrieved from a database by the operator console when processing the call. One manner in which this can be accomplished is through the use of DEF records as discussed below.
The caller responds with the requested information. This information could be verbally provided to a human operator, who then enters it into the system via the operator console, or could be a sequence of one or more keys pressed on the telephone keypad. The information requested of the caller can include: the number to be called (if not originally entered on a 0xe2x88x92 call); billing information such as a calling card number, enhanced services card number, credit card number, debit card number, or telephone number to be billed; a feature identification (for example 2# for speed-dial); a security code; and other like information.
The information entered is validated to ensure that it is correct and that the call can be completed. One method of performing validations is to do an internal validation. For example, the called number is validated to ensure that it is the correct number of digits or terminating number is validated to ensure that the call is being placed to an area that is within that caller""s allowed calling area (if restricted).
Alternatively, a validation system, which is part of the call processing system, could be used to validate other information required to complete the call. Billing information can be validated to ensure that the method of billing is acceptable. Credit card numbers can be checked through validation service providers and debit cards can be checked to determine whether the balance is sufficient to place the call. Security codes can be checked against the feature to be accessed, the originating number, the billing information, or other parameters screened through the use of the security codes.
If the information entered is invalid, the caller may be given a second chance to re-enter the correct information, or alternatively, the call may be terminated. If the call is being handled by a VRU, the VRU may transfer the call to a human operator to provide additional assistance. The number of chances provided to a caller who enters incorrect information, whether and when the call is transferred to a human operator, and when the call is terminated due to invalid information is customizable to the customer and user, as parameters in the DEF record.
If the information is valid, the operator console sends data to the NCP indicating that the call can be routed to the terminating (called) number. The NCP performs a number translation, where required, to determine the proper routing for the call. Once the routing is determined, the NCP generates instructions to command the switch to route the call to the destination. In one embodiment, the switch instructions are packetized for transmission via a LAN. A gateway removes the instructions from the LAN packet(s) and formats them into a form that is recognized by the switch (SS#7). The NCP also releases the operator console from the call so that it is free to handle another call.
The switch routes the call to the destination via a telephone network based on the instructions received from the NCP. Standard telephony signalling can be used to complete the call to the called number. This includes call accept messages (for example, ACMs) and answer messages (for example, ANMs).
If the call does not require operator assistance, the operator allocation steps and the operator handling steps described above can be bypassed. In this case, the called number can be validated to determine whether the call can be completed. This can include validations to determine whether the call is to an acceptable calling area and whether the called number contains the correct number of digits.
The validation system can be used to validate billing information, and information i.e., whether a credit card number is valid for credit card calls.
When an operator console wishes to validate call information prior to the completion of a call, it sends a validation request to the validation system. The validation request includes an index and call data or other information to be validated. When the validation system receives the request to perform a validation, it retrieves validation instructions, termed xe2x80x9cp-code,xe2x80x9d from a database. These instructions contain the process to be followed in validating the information. In one embodiment, the index provided with the validation request indicates the specific p-code instruction to retrieve for that validation. The operator console requesting the validation determines the index and provides it with the request. In one embodiment, the index is defined based on the call type. Thus, for each call of the same type (i.e. for each calling card call, or for each credit card call, etc.), the index points to the same p-code instruction. In alternative embodiments, the index can be uniquely defined at the user and/or customer level to customize the validation process at this level.
The retrieved p-code instruction provides information to the validation system regarding validation of the call. For example, the p-code instructions may tell the validation system that it must first look for the originating number (ANI) in a hot/cold database. If the number appears as a xe2x80x9chotxe2x80x9d number, the validation fails and the call should not be completed for that number. An example of when this occurs is when an originating number is used to place fraudulent calls. This number can be put in the hot file to stop toll calls from being placed from that number. If the number appears as a xe2x80x9ccoldxe2x80x9d number, that call is to be completed without further validation. This could be used for calls originating from a number where time is of the essence.
The p-code may then instruct the validation system to validate the call against a validation index file. In this validation step, the call data (for example called number, originating number, originating area code, etc) is validated against various parameters to determine whether the call should be blocked. If the call is blocked, a response is sent to the console indicating that the call cannot be completed.
The p-code may also instruct the validation system to perform an external validation. One example of where this is useful is where a credit card number is to be validated via an external credit card validation service. In this step, the outside source is contacted via modem or other datalink and provided with the information to be validated. The outside source performs the validation and responds with a positive or negative response. If the information is invalid, a response is sent to the console indicating that the call cannot be completed.
A key feature provided by this architecture is that changes to the validation process can be made quickly and easily by simply updating p-code in the database. Operational code of the validation system does not have to be recompiled to implement changes to the validation process.
The call processing system also can include a billing system for determining the rates for calls and services, determining the costs for calls and services, and for generating bills to bill subscribers of the call processing system. The billing system includes a rating system, a rate file, and a toll file.
The billing system can provide rate quotes for a call that tell the requestor how much a call will cost. This feature can also be used by the call processing system to determine when the dollar amount left on a user""s debit card is going to be depleted. In one embodiment, when a user places a debit card call, the operator console requests a rate quote from the billing system. The billing system looks up the rate for the call in the rate file. The rate can be based on the time of day, the distance over which the call is placed and the particular customer or user placing the call.
The billing system provides the quote to the operator console and to the NCP. The NCP retrieves information indicating the remaining dollar amount on the credit card. The NCP then computes the amount of time that is remaining on the card based on the rate quote for the call and the remaining dollar amount. When the remaining time is about to expire, the user is provided with a warning indicating how much time is left. When the time expires, the call can be terminated or the user given options to replenish the debit card.
When a call is received by the call processing system for routing, a billing information record (BIR) is generated for the call. Among other information, the BIR is updated with timing information such as when the call is completed to a VRU or to an operator console or when it is terminated. When the call is completed, the BIR is sent to the billing system so the cost of the call can be calculated. The billing system uses the time information to compute wholesale and retail call durations. The billing system uses other information contained in or derived from the BIR such as time of day and distance of the call to retrieve a rate for the call. The billing system calculates a cost for the call (wholesale and/or retail) using the appropriate rate and the call duration. If required, a tax for the call is computed and added to the cost of the call. The cost information is stored in a toll file from which bills can be generated and sent to the appropriate subscriber.
According to one embodiment of the present invention, call processing is performed using what are known as DEF records. The call parameters determined by the NCP when a call is received include information pertaining to a DEF record and a base process for processing the call. This information is provided to the operator console in the form of a base process number and a DEF record number. In processing the call, the operator console starts the base process identified by the NCP. The base process is the basic process that is to be followed by the operator console in handling the call. It can include the basic steps to be followed by the operator console and can be coded to look for specific data (identified by tag numbers) in a DEF record, respond to certain types of information contained within the DEF record, or wait for and respond to information received from the caller.
The base process is started by the operator console. The base process indicates the data (using tag numbers) to be retrieved from the identified DEF record, and the order in which it is to be retrieved. This data contains information regarding steps to be performed in processing the call. The data may indicate that certain scripts are to be played (or synthesized or read) to the caller, that certain validations are to be performed, or other processes started. The data may also indicate the actions that are to be taken in response to key entries made by the caller. When the base process is finished, it runs a finish process. The finish process may point to another process to be run or it may point to a complete process used to complete the call.
Because call processing is controlled using data records, one advantage of using DEF records is that changes to the manner in which calls are processed can be implemented by changing the data in the data records. An additional advantage is that call processing can be customized for a specific user or customer. Because the particular DEF record chosen for call processing (initially) is selected based on call data, changes to the DEF record selected can result in changes to the way the call is processed. Thus, one DEF record may indicate that a certain script is to be played or that certain information is to be validated or that key sequences input by a user are to be responded to in a certain way. Other DEF records may indicate other operations to perform or other ways to respond to user input when processing a call. Thus, it is the DEF record that defines how a call is to be handled.
Changes to the data in databases of the call processing system can be made using a distribution system. For redundancy, certain databases are mirrored to provide a high degree of fault tolerance. To maintain integrity of all databases, changes to any of the master databases must be made to all affected slave databases as well. To accomplish this, the call processing system uses a distribution system, which captures the changes made to tables in the master database and updates the affected slave databases with these changes.
A trigger captures changes made to the master database and stores these changes in a delta table. A distribution server retrieves these changes and creates a net message table indicating the changes to be made and an audit table indicating the slave databases affected by each change. The distribution system then updates the affected slave databases using the messages in the net message table.
One advantage of the distribution system is that triggers are used to simplify the operations performed and to ensure the integrity of slave databases throughout the entire call processing system. A trigger is called each time a change is made to the master database. The distribution system is transparent to the application making changes to master database. The application making the changes to master database is not involved with the process of modifying the slave databases with the same changes.
The use of a delta table is another advantage of the distribution system. Through the use of the delta table, only the data that is needed to update slave databases is provided to the distributor. The changes are then read from the delta table to be applied to the appropriate slave databases. This method allows the application performing the change to the master database to continue performing any other activities required, while the distribution system makes the changes to the appropriate slave databases.
Still another advantage of the distribution system is that it does not require that updates to all databases be simultaneous. This feature allows slave databases to be updated at their own pace. If any one of the affected slave databases is down, the changes are queued until that database is ready to receive them.
The call processing system can also provide real-time monitoring, detection, and prevention of fraudulent uses of the system. This functionality is provided by a fraud system. The fraud system handles and detects fraud in both calls that successfully complete (go through), and calls that fail. The fraud system is an integrated system that monitors manual operator consoles, automated VRU consoles, as well as the NCP and the billing system. Specific fraud consoles are provided to fraud administrators assigned to the task of fraud detection and prevention. These individuals can monitor the operation of any call in the system in real time and can take any necessary actions for fraud detection and prevention. Automatic database storage of critical data associated with detection and prevention is provided. Alarm levels can be set so that when data exceeds specified limits, an alarm is triggered to a fraud administrator. The architecture of the system allows for specific fraud scenarios to be detected and prevented. The present invention is robust enough to accommodate additional fraud scenarios in the future.
Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.